This question and answer file contains APPN-related questions from APPN vendors and customers, and the answers provided by APPN architects and product designers, where appropriate. These Q&As deal with the following subjects, in that order, over the period Apr. '93 - July '93. Subject: Wellfleet's questions about TGs and RTP connections in HPR Subject: Connection network confusion Subject: SNA Configuration Disk Subject: More on Connection Networks Subject: Nonactivation XIDs Subject: APPN Sessions Subject: APPN over ATM Subject: Routing through ENs? Subject: APPN Naming Conventions, NetID Registry, Border Node Products Subject: APPN Subnets & Border Nodes Subject: End Nodes on Connection Networks Subject: Data Compression Subject: Border Node Subject: APPN Reference Manuals Subject: Internetworking in APPN Subject: Peripheral Border Node Subject: Dependent LUs in APPN ----- APPNQA FORUM appended at 15:07:23 on 93/04/26 GMT (by MPETERS at RALVM6) Subject: Wellfleet's questions about TGs and RTP connections in HPR QUESTION --------------------------------------------------------- From: pphillip@wellfleet.com (Paul Phillips) Cc: pgp@wellfleet.com I had a couple of questions trying to understand how HPR works, and the relationship of RTP to PC. I wanted to send them to you while they were still fresh in my mind, but please don't feel like I need an immediate response. My lack of understanding concerns TGs and HPR. In order to calculate route suitability I presume each HPR link is configured as a TG with certain TG characteristics. Is this true? If so, wouldn't one expect a separate instance of PC for each TG? I believe the intent is that multiple paths chosen by HPR would manifest itself under a single instance of PC, and here is where I am confused. Also, could a TG that supports both HPR and ISR have different TG characteristics for HPR and ISR usage? Is an RTP logical link a TG? Please illuminate where possible. Thanks for your help. Paul ANSWER ----------------------------------------------------------- From: Ray Bird BIRD at RALVM6 TGs in HPR are basically used the same as in APPN. They have a TG number, characteristics, are broadcast and kept in topology, and are used (in conjunction with COS) for calculating routes. If a TG is activated between 2 nodes that are HPR capable, the TG is designated as HPR capable. This HPR capable property is kept in topology (even by non-HPR capable nodes) but is not used when calculating routes. It is used by HPR level nodes to determine the RTP connection end points. Except for this HPR capable indicator, all other characteristics of the link are defined the same as in APPN. RTP connections (used by HPR capable nodes) are different than TGs. They are not kept in topology and are not used in calculating routes. They are a logical "pipe" designed to transport session traffic in an efficient manner with the additional capability of being able to route around failed links. An RTP connection is activated when needed (i.e. triggered by the first BIND) and deactiavted when no sessions are using it. The HPR capable property of the links allows the end points of the RTP connections to be determined. In today's APPN there is one path control associated with each link. This is not an invariant principle but rather just turned out that way. For example, if multi-link TGs were implemented there could be one PC for many links. In HPR there is one PC for each RTP connection. The function of PC is to multiplex and de-multiplex sessions that share a single RTP connection. In this sense, RTP appears as a "logical link". Please let me know if you need further clarification or have any additional questions. Ray ----- APPNQA FORUM appended at 15:46:20 on 93/05/04 GMT (by MPETERS at RALVM6) Subject: Connection network confusion QUESTION: ------------------------------------------------------------ I was pitching APPN to a customer, and explaining connection networks in the process. From a course they had had on APPN, the customer was convinced that we could only have ONE node representing a Virtual Routing Node (VRN) Which is of course NOT my understanding. Can you confirm that multiple Network Nodes can be used SIMULTANEOUSLY as the de-facto servers for the connection network configuration ? (in other words, each other NN sends its TDUs to more than one NN, so that a single node failure does not break the system) If the previous statement is wrong, can you confirm that in case the deisgnated NN fails, another one can take the function over? As a side question... can't we define SEVERAL VRNs on a single LAN? (but of course a given NN is only attached to one VRN - with interconnection between two VRNs mandating going thru ISR in an NN) Do you know of any PRODUCT LIMITATION in implementing the VRN that could explain the customer belief (they have AS/400s today) ANSWER: ------------------------------------------------------------- Connection networks can represent connectivity between any kind of APPN nodes, e.g. EN-VRN-EN, NN-VRN-NN, NN-VRN-EN. As the architecture stands today, CP-CP sessions are not supported over connection networks. The architecture allows a node to have connectivity via more than 1 connection network. For example, an EN could represent its connectivity to other stations on the same LAN using one VRN, and its connectivity to an X.25 PSN using a different VRN. Another reason to have >1 CN per node might be to represent different link characteristics or route addition resistance. An EN can be in a configuration where it has physical attachments to >1 NN. This is, or should be, a common configuration for fault tolerance. ENs today have 1 NNS at a time, but this is not an architectural limitation: it's just that to date, having multiple NN servers for an EN provides no added value, so why do it? Having one NNS per EN has minimal customer impact, because the EN can always go to a different NNS if the first one fails. :(A) Every time a new session is to be established, the EN does a Locate to its NNS. The EN provides a list of its TGs and connection networks with the Locate. The destination EN includes similar information about its TGs and CNs on its Locate reply. This information arrives at the origin EN's NNS, for route calculation. In computing the route, the NNS considers the mode/COS, network node topology including NN resistance values and TG characteristics (including possible CNs between NNs), and EN connectivity information (TGs and CNs). Therefore more than one CN can be specified and considered in the route calculation. In today's APPN (ISR), if a link or node on the path fails, the session fails and the session endpoints are disrupted. (However, a well-designed application can often reestablish a session transparently to the end-user.) Let's consider two cases. (1) The session route is EN-VRN-EN. If the EN-NN CP-CP session fails, the LU-LU session is not affected. (2) The session route is EN-NNS-VRN-NN. If the EN-NN link breaks, both the EN-NN CP-CP session AND the LU-LU session fail. In this case, the EN must select a new NNS before it can reestablish the LU-LU session. Assuming an alternate NNS is available, paragraph (A) describes the use of a CN with the new NNS (i.e., no different than with the first NNS). (Note: APPN function set 1015 is part of the APPN version 2 base architecture; it makes switching servers very easy. Not every product is at V2 level today; some older products require operator intervention to switch servers. Switching servers should not be a problem for AS/400, VTAM V4R1, or Comm Mgr since they all have the new function.) Marcia Peters ----- APPNQA FORUM appended at 20:42:24 on 93/05/04 GMT (by HEFEL at RALVM ) -- Subject: SNA Configuration Disk Ref: Append at 16:40:20 on 93/05/04 GMT (by hefel at RALVM6) Question from Stephen Lubbs: Is there any plan to move the info that is available in the IBM Inf Net SNANS store to the APPC forum on CompuServe? That would be helpful. There were a number of helpful infobits in there. Yes, we do plan to move some of the SNANS stuff to the forum. John O'Donnell is currently working on this. He won't be moving everything up, but will move anything deemed appropriate. He expects to have this done by mid-May. Security(Public/Private): Public Architect: Tim Hefel ----- APPNQA FORUM appended at 21:24:53 on 93/05/06 GMT (by MPETERS at RALVM6) Subject: More on Connection Networks QUESTION: (Long question follows) ----------------------------------- Just to make sure, I have re-drawn what I had explained to the customer (which he told me conflicted his understanding). Let's have a connection network (********), like a token ring Let's put 6 NNs on it (A, B, C, D, E, F). I am not worried about ENs that could be on the same CN, or hanging from some NNs. I was explaining the customer that we could decide to establish only a few of the CP-CP sessions that would be needed if every NN were having a CP-CP with all its neighbour (that would be 6x5/2= 15 double sessions). We could pick 'A' and 'B' as the "TDU distributors", and have C, D, E, F all have CP-CP with both A and B - for a total of 4x2= 8 double sessions (9 if A and B also have a CP-CP, as shown, which is probably a bad idea). The CP-CP sessions are shown as straight lines. I did not represent all of them. From your answers, I conclude that: -- this is a perfectly valid way to configure the system Each NN is defined with two MAC addresses (A and B) to establish a TG with -- all NNs will have total topology, a nothing breaks if A or B fails -- still, if a session needs be routed between C and F, these guys will compute the direct route (thru the VRN) that bypasses both A and B -- while that route will necessitate establishing a link between C and F, C/F will NOT set up a CP-CP path, that would then be reported thru TDUs Ú----¿ Ú----¿ | NN d--------------------------Q NN | | A d-------¿ Ú--------------Q B | À -- Ù | | À -- Ù | | | | | | ******|**|********|***|***************|**|******* * | | | | CONNECTION | | * * | | | | NETWORK | | * * | | À-----------¿ | | * ******|**|************|*******|*******|**|******* | | | | | | Ú----¿ | | Ú----¿ | Ú---¿ | | Ú----¿ | NN d---Ù À---Q NN d---Ù | NN d---Ù À---Q NN | | C | | D | | E | | F | À----Ù À----Ù À----Ù À----Ù If, on the other hand, I turned C and F to be ENs, instead of NNs: -- they would each pick ONE NNS -- they would also end up with a direct path (thanks to the VRN being added to the computation of the route). ANSWER: ------------------------------------------------------------ Yep, you got it. For now, defining the CP-CP sessions is a manual activtity. The only correction I have to your note is that when a link is activated between C and F to support some LU-LU session, it is very possible that they will automatically establish a CP-CP session. It all depends on what the node C and F products put in their XID3 for the connection network. If they happen to specify that the link they are activating supports CP-CP sessions, they will automatically be activated. My recommendation is, of course, not to do this. And I don't know whether existing products allow the customer to control this aspect of link activation over a connection network between NNs. ----- APPNQA FORUM appended at 18:11:54 on 93/06/01 GMT (by HEFEL at RALVM6) -- Subject: Nonactivation XIDs Ref: Date: 05/18/93 Owner: Sutinder Sethi Compuserve? YES Question: APPC Info Exchange Forum I really wanted to know was how in real life I could make generate this non activation XID (preferably with the CPName changed. What should I do at the host end to generate this ???? Answer: You cannot make today's released VTAM product generate a nonactivation XID with changed CP name. V4R1 is the first VTAM release that will be able to generate that line flow. Here is the configuration: ................... : ÚÄÄÄÄÄÄÄÄ¿ :ÚÄÄÄÄÄÄÄÄÄ¿ : | VTAM1 | :| VTAM2 | : ÀÄÄÄ+ÄÄÄÄÙ :ÀÄÄÄ+ÄÄÄÄÄÙ : TG1 | : |TG2 : FID4| ÚÄÄÄÄ¿: |³FID4 : ÀÄÄÄÄÄ+NCP1+ij³KÄÙ : ÀÄÄ+ÄÙ: :..............|..: |T2.1 TG3 ÚÄÄ+ÄÄ¿ |APPN3| APPN unit under test ÀÄÄÄÄÄÙ VTAM1 and VTAM2 must be at the V4R1 release level and NCP1 at the V6R2 release level. Configure FID4 connections between VTAM1 and NCP1, and between VTAM2 and NCP1. Define both VTAMs as APPN network nodes. Make VTAM1 the owning SSCP for NCP1. This makes VTAM1-NCP1 a composite network node (i.e., NCP1 looks to APPN3 like part of the VTAM1 node.) Define all links as supporting CP-CP sessions. Bring up all the links. VTAM1 should send XID3 with its CPname to APPN3 and they should establish CP-CP sessions. Now bring down VTAM1 or TG1. VTAM2 should do a SSCP-takeover (assume ownership of NCP1). When it does this, APPN3 should receive a nonactivation XID over TG3 from VTAM2, with a new CPname of VTAM2. You can also reactivate VTAM1 and TG1, and do an SSCP giveback at VTAM2. This will cause VTAM1 to assume ownership of NCP1 and send a nonactivation XID saying that the composite node's name is now VTAM1. Security(Public/Private): Public Architect: Marcia Peters Comments: ----- APPNQA FORUM appended at 18:16:10 on 93/06/01 GMT (by HEFEL at RALVM6) -- Subject: APPN Sessions Ref: Append at 17:23:46 on 93/06/01 GMT (by HEFEL at RALVM6) Date: 05/18/93 Owner: James Rendell Compuserve? YES Question: I have just read the following thoroughly confusing paragraph in a Xephon journal : "Because of its Type 2.1 Node heritage, and in marked contrast to SNA, APPN does not have a concept of an end-to-end session. (Type 2.1 Nodes were designed for direct, peer-to-peer, point-to-point interactions between logically adjacent nodes). "Thus all Type 2.1 connections are point-to-point, without any provision for intermediate routing nodes. "Consequently, an (note the next bit carefully...) *end-to-end APPN session* that traverses multiple, intermediate NNs, has to be constructed in the form of a series of 'session stages' between each pair of nodes...." This sounds like claptrap to me. He starts off saying that there is no concept of end-to-end sessions in APPN (hoots of laughter from off the stage :-), and then describes how the very concept is implemented. This person must be wrong because when an EN talks to another EN through a couple of NNs, the LUs in the ENs BIND, so there's a session. I think what the guy means is that there is no actual logical 'pipe' as in a subarea network. Whilst there are TGs between each NN, there is not one TG that logically goes from EN to EN, or any kind of ER or VR. Also his "session stages" must bear some resemblance to the CP-CP sessions between each node. The passage goes on to assert that the NNs perform routing of each PIU f in the session by swapping the value in the LFSID field in the TH to reference the LFSID field for the session with the next node in the session route. Is this true ? Is this how APPN routes individual PIUs ? If so, since an NN understands the whole network topology, why can't a PIU be sent to another adjacent node if there is a problem with the connection (like in IP) ? Is this what is coming in APPN+ ? Industry watchers are a pest. All they do is create confusion ! I thought I understood APPN until this Xephon report. Answer: - The paragraph in the Xephon journal is wrong, there is an end-to-end session in APPN. Take the example given above where a session is activated between two ENs that traverses multiple NNs. A bind is sent from the origin EN along the path to the destination EN. In general, this bind sets up session connectors (i.e., LFSIDs) at each node on the path, and they will be used later for routing the PIUs; think of it like a label-swapping mechanism. The session end-point flows/functions (i.e., LU6.2) are still performed at the two ENs. The intermediate nodes will perform the routing function of the PIUs (LFSIDs swapping) including the hop-by-hop adaptive pacing. There is NO full session end-point functions performed at each node as described in the paragraph. - A NN can forward PIUs to the destination through different adjacent nodes (i.e., different paths) but some mechanism has to be put in place to clean up the session connectors on the old path, resend the BIND on the new path, and notifies the end-points of the new path etc.. Unlike IP, APPN is a connection oriented protocol and each intermediate node has knowledge of all connections/sessions going through it. As a result, performing a pathswitch in APPN is much more involved. And yes, this function will be available in APPN+. Security(Public/Private): Public Architect: Lap Huynh Comments: Lap, fill out this form (put your answer in the answer portion of this file) and send the file to APPN1 at Ralvm6. An answer by end of today would be appreciated. NOTE: some of the text is truncated on the right side, but the missing letters should be obvious. ----- APPNQA FORUM appended at 18:17:06 on 93/06/01 GMT (by HEFEL at RALVM6) -- Subject: APPN over ATM Ref: Append at 17:23:46 on 93/06/01 GMT (by HEFEL at RALVM6) Date: 06/01/93 Owner: Mike Latriano Compuserve? No Question: Is there an RFC being developed for APPN over ATM??? Answer: The APPN specification in general is DLC independent. That is, our Path Control element sends FID2 messages to the DLC component. The specific DLC, then sends the FID2 over the transmission media using the DLC defined algorithms. In this sense, implementors could put APPN over ATM today. A key point to note, however, is that APPN/PC treats the DLC layer as if it were a point to point connection to an adjacent node (like the typical leased line scenario). ATM like many other DLCs, however, provides additional DLC level services which APPN should take advantage of. At this point, there is a work project amongst the IBM APPN architecture team to study the important new DLC types: (Frame Relay, ATM, FDDI, MAN, Wireless, FCS, etc) and determine what modifications are necessary to utilize the features o these subnets most efficiently. It is possible that this work group activity could be brought into the AIW as well as a special interest group perhaps. If you are interested in this, please let me know or better yet, suggest it at the AIW. Security(Public/Private): Public Architect: Dave Bryant Comments: ----- APPNQA FORUM appended at 16:49:25 on 93/06/08 GMT (by HEFEL at RALVM6) -- Subject: Routing through ENs? Ref: Append at 18:17:06 on 93/06/01 GMT (by HEFEL at RALVM6) Date: June 7, 1993 Owner: David Matusow - Hypercom Compuserve? No Question: I don't think this configuration is valid, but I need to get a true architectural answer. A client wants to create the following configuration, but I don't think that it is architecturally correct. What they want is to create a network with, let us say, 4 interconnected nodes. The following shows the network. +----------+ +----------+ +----------+ +----------+ | | | | | | | | | EN1 ------ EN2 --------------- EN3 ------ EN4 | | | | | | | | | +----------+ +----------+ +----------+ +----------+ |------------------------ session ------------------------| If EN1 has a cached path to EN4, could it establish this session? Would the route just appear as, assuming that all TGs are TG1: EN1,TG1,EN2,TG1,EN3,TG1,EN4 Is anything gained or lost from this? What if there weren't a cache in EN1, but a predefined route? Is this predefined path valid? How could network management be conducted? (I assume that if the route is valid, this would be communicated and management would be both possible and robust.) Can you have a "APPN network" without any NN? Answer: It is not architecturally valid to route through an APPN EN. This is because the APPN EN does not have the Intermediate Session Routing component. In addition, ENs do not participate in the topology algorithms of APPN. Lastly, ENs do not have the capability to compute or cache session routes. So this scenario is not architecturally possible or supported. Predefined routes are possible, but the architecture for them is not currently defined. Implementations could provide this function, but may run into interoperability problems in the future. APPN networks without NNs are possible as long as the ENs are directly connected. But given that two ENs cannot have CP-CP sessions, the network might as well be a Low Entry Networking (LEN) network. No advantages of APPN will be realized without NNs. Security(Public/Private): Public Architect: Dave Bryant ----- APPNQA FORUM appended at 21:00:54 on 93/07/06 GMT (by HEFEL at RALVM6) -- Subject: APPN Naming Conventions, NetID Registry, Border Node Products Ref: Append at 16:49:25 on 93/06/08 GMT (by HEFEL at RALVM6) Date:7/6/93 Owner: Rainer Foeppl Compuserve? Y Anthony Johnston The following is an ongoing discussion between two implementors concerning naming conventions within the APPN architecture. Dave Bryant answers any lingering questions at the end of the discussion. Question: Rainer: Does anybody out there care about the naming of APPN resources in the the network? Anthony: I too am interested in APPN naming conventions. I am beginning an investigation into the (possible) use of APPN for a 20 (subarea SNA) SNI based network. We currently use a naming convention based on subarea and an alphanumberic representation of the NETID. I would be interested in any comments/thoughts anyone has. The network is currently 3270 LU2 based but we are planning to utilise LU6.2 more in the future. Rainer: We are trying to figure out, on what OS (MVS, OS/400 ...) what level of APPN is supported. This is very important, as we need this knowledge to design a migration path that can be followed by any machine used in our network. We identified two major problems: 1.) There is a lot of border-node support missing. Some of the support may be circumvented by the use of non-native-network-attachement. 2.) We aren't sure if all APPN-levels support the same name for CP and ILU. What do you think? Anthony: Hi, I'll need some time to consider these questions, but I think VTAM insists on separate names for CP and ILU - I'll try to confirm this. Peter Schwaller: I run APPC appls to VTAM from my CP LU every day. I believe the restriction you're referring to is that VTAM doesn't allow a workstation CP name to be the same as its PU name. I believe that since the PU name doesn't flow (?) this is a VTAM only configuration hassle. For instance I only configure a CP name with OS/2 CM, never a PU name. Rainer: I think you just got the point: There are many bits of information flowi around, but there is nobody who could put them together to form a unique picture. But we need the complete picture to do a good implementation of APPN... There is a lot of documentation to be done by the architects.... Dave Bryant: Gentleman: Naming conventions are a matter of customer choice and configuration designed to accomodate customer needs. Architects cannot help you here, consultants may be of more use. Naming restrictions, however, are within the realm of architecture. The APPN LU namespace is exactly the same as it is for Subarea SNA. LU names are composed of a NETID.LU construct. Both the netid and LU name are 1 to 8 bytes in length. They must be comprised of letters from character set 1134 (A...Z, 1...9, @, #, $) with the first character of each being non-numeric. In addition, it is strongly advised not to use the @, #, $ as these characters are not internationally recognized and many non-domestic devices cannot display or enter them. In addition, one should note that IBM has established a Netid registry. It is strongly recommended that all customers register their netids through this registry process. This is the only way to guarantee LU name uniqueness as we all merge into a world-wide internetwork. Procedures for this registry are defined in manual ZZ27-7425. From a directions standpoint, it is IBM architectures intent to locate resources in a hierarchical manner by first locating the appropriate Netid networks and then the specific LU(s) within that network. Therefore, network naming will have some impact on overall internetworking performance. With respect to Border Node function, both OS/400 and VTAM 4.1 support Peripheral Border Node, while VTAM 4.2 supports Extended Border Node. One should anticipate further support of this function in other products in the future. With respect to PU names vs. LU names vs. CP names, you will find the VTAM restrictions on this matter documented within the VTAM V4R1 manuals. This is not an architectural issue or restriction, but a VTAM one. More or less, PUs are defined and known only at VTAM. VTAM will ensure that a given PU name does not refer to multiple things. Hence a PU name cannot match a CP (or LU) name. With respect to naming and product interoperability, there is some discussion of this topic in GG24-3669 "APPN Architecture and Product Implementations Tutorial". Since the questions mentioned in this memo are somewhat general in nature, I'm not sure how much more information I can provide. If there are any more specific questions, I will do my best to answer them. ----- APPNQA FORUM appended at 12:18:50 on 93/07/08 GMT (by HEFEL at RALVM6) -- Subject: APPN Subnets & Border Nodes Ref: Append at 21:00:54 on 93/07/06 GMT (by HEFEL at RALVM6) Date: 7/07/93 Owner: Dave Matusow Compuserve? N Question: What is the current status of subnetworking in APPN? I note in the architecture document that option set 1016 provides this service, but it is not clear what the impact on topology updates with this option. Would a NN connecting to a non-native network get flooded? What stops this, except to exclude this exchange in the XID3? Answer: APPN subnetworking is accomplished with something called a Border Node. This function is currenlty shipped in OS/400 V2R1 and beyond and I believe is known as Multi-network Interconnect (or something like that). Nodes connecting to non-native adjacent nodes are not flooded with topology. In order to accomplish subnetworking, no topology flows between subnets. The topology segregation is accomplished when the BN represents itself as an APPN EN to non-native adjacent NNs. Since topology flows do not occur between NNs and ENs, the topology segregation is natural. The BN then modifies the associated resource hierarchy in FIND and FOUND GDS variables that cross the network boundaries so each network is none the wiser. You can obtain overview level descriptions of this function in the following documents: APPN Architecture and Product Implementations Tutorial (GG24-3669) and APPN Architecture Reference (SC30-3422) chapter 1. With respect to function set 1016 (Extended Border Node), this is currently undocumented function. It is also not shipped and only a statement of direction. For this reason I cannot enter into discussions of how the topology segregation is accomplshed. But let me suggest that it COULD be accomplished in one of two ways: - As described above with an NN/EN appearance - By simply not sending TDUs between two non-native BNs Security(Public/Private): Public Architect: Dave Bryant Comments: ----- APPNQA FORUM appended at 14:39:53 on 93/07/14 GMT (by HEFEL at RALVM6) -- Subject: ENd Nodes on Connection Networks Ref: Append at 12:18:50 on 93/07/08 GMT (by HEFEL at RALVM6) Date: 7/12/93 Owner: Anonymous Compuserve? N Question: In investigating an APPN End Node implementation for my company, I ran into a discrepancy(?) in the APPN Architecture Reference. I hope this doesn't sound too stupid, but I'm confused & would appreciate some help. In Appdx A (p. A-10), the table shows that option set 083 (Member of Connection Network) is a part of the base. However, chapter 9 (pp 9-57) states the EN represents the connection network by using a VRN in the TG vectors reported to the NN during the search process. This seems to imply that the EN supports option set 008 (Multiple TGs), which is an optional set. Answer: 1- You are correct, if the EN is going to be on a CN, then it will have to support multiple TGs. 2- The original option set 008 thinking was: - An EN could get by with only one non-CN link to it. 3- But since your EN product should support CNs, then you must code to that option and thus your box will also automatically support multiple TGs. Security(Public/Private): Public Architect: Jim Amundson Comments: ----- APPNQA FORUM appended at 14:40:27 on 93/07/14 GMT (by HEFEL at RALVM6) -- Subject: Data Compression Ref: Append at 12:18:50 on 93/07/08 GMT (by HEFEL at RALVM6) Date: July 13, 1993 Owner: Ed Holt Compuserve? Y Question: In VTAM V3R41, IBM introduced a new SNA control vector for data compression. As of today, this feature is only available between PU T5 nodes. Does anybody know whether APPN will add this feature as standard in the forseeable future. The reason I ask is that I have to do a study on compression code for our VTAM applications. If I can convince management that soon this feature will be performed by the supporting PU node type for dependant and independant LU's in APPN or SN environments, then a lot of development time will be saved. Answer: SNA's data compression (officially known as Length-checked compression or LCC) was designed to be independent of node type and LU type. At this time, only communication between LUs on VTAM can use LCC. However, I'm certain that you will be pleasantly surprised to see the number of other IBM products that will ship compression support within a year (sorry that I can't be more concrete/less conservative). Here's the publicly available information: 1) in 2/93, Rochester announced compression support would appear in version 2 release 3 (the ext release), scheduled by year's end 2) Comm Mgr expects support compression well within a year's time (6-9 months) 3) Networking Services/DOS expects to include compression within a year's time Questions? Please let me know. Security: Public Architect: Alan Yueh(yucko@vnet.ibm.com) Comments: ----- APPNQA FORUM appended at 20:17:04 on 93/07/16 GMT (by HEFEL at RALVM6) -- Subject: Border Node Ref: Append at 14:40:27 on 93/07/14 GMT (by HEFEL at RALVM6) Date: July 16, 1993 Owner: Rainer Ciba-Geigy Compuserve? Y Question: Please confirm or give comments on my personal understanding of APPN-Architecture (not implementation in current or future products): A Networknode (NN) must always attach to a NN with the SAME NETID. It cannot attach to a NN with a diffrenet NETID. A NN can attach to a Endnode (EN) with a different or same NETID. Is that part of the architecture or is it just implementation of some software-products? Thank you very much for your help Answer: A Network Node CAN attach to another Network Node with a different netid in APPN networks. One of the two network nodes, however, has to be a border node. This node is seen as an End node to the other network node, although it acts as a network node within its own network. An end node can attach to a network node with a different netid without any stipulations, and yes, it is part of the architecture. Security(Public/Private): Public Architect: Tim Hefel Comments: ----- APPNQA FORUM appended at 15:40:24 on 93/07/19 GMT (by HEFEL at RALVM6) -- Subject: APPN Reference Manuals Ref: Append at 20:17:04 on 93/07/16 GMT (by HEFEL at RALVM6) Date: July 17, '93 Owner: Joseph Pistritto Compuserve? Y Question: To: APPC/APPN Forum Sysop,76711,370 Can you give me the name of a good reference on APPN architecture? I'm familiar with LU6.2 and SNA in general, but not APPN. I have some of the refernce material that was distributed at the APPC Conference in San Francisco last year, is that the best source? Answer: Joseph, Regarding your request to the APPC forum for documentation on APPN, there are some very good manuals out there. The 'APPN Architecture and Product Implementations Tutorial', order # GG24-3669-00, provides a good overview of APPN. The manual 'Systems Network Architecture Advanced Peer-to-Peer Networking Architecture Reference', order # SC30-3422-03, provides all of the details on every feature, both base and options, of the current APPN architecure. These two manuals should give you plenty to chew on regarding APPN. Also, the SNA Formats manual describes the SNA formats used between subarea and peripheral nodes, between APPN nodes, and between APPN and low-entry networking (LEN) nodes (GA27-3136-13). Security(Public/Private): Public Architect: Tim Hefel Comments: ----- APPNQA FORUM appended at 15:19:09 on 93/07/21 GMT (by HEFEL at RALVM6) -- Subject: Internetworking in APPN Ref: Append at 15:40:24 on 93/07/19 GMT (by HEFEL at RALVM6) Date: July 19, '93 Owner: David Matusow Compuserve? N Question: One more question on internetworking in APPN. Since Border Node does NOT support ISR, an LU cannot establish a session THROUGH a non-native network to a 3rd network. But is it possible to accomplish this through pre-definition? I don't think this would assist in the creation of the appropriate session connectors, but there might be something that I'm not thinking of in this instance. The other possible method might be through a VTAM composite node. It would seem that the APPN network might be able to create a session by using VTAM's SNI facility and "fake" the APPN network out. In this case, it would seem that one could flow through the SNI connection and join back up to a disconnected APPN on the other side. The figure below shows how this might work. +----------+ +----------+ | net2 | | | | |---- SNI ----- | net3 | | | | | +----------+ +----------+ It would seem that no matter what networks exist in the SNI, a session could be established from net2 to net3. Is this true? Answer: Remember, there are two levels of border node function: (1) what AS/400 implemented, called Peripheral Border Node, which supports routing only between adjacent subnets (i.e., no intermediate network routing, cannot route from network A thru network B into Network C) and (2) what VTAM will implement, called Extended Border Node, which does support intermediate network routing. I covered this topic in the Overview chapter of the APPN Architecture reference, if you have it. It would be possible to kludge up some LEN network definitions in order to force a Peripheral Border Node to forward a BIND across a LEN link to a third network, but if the network definitions weren't carefully coordinated, that network might very well send a BIND right back! It's do-able, but ugly and messy and error-prone. This approach would require additional administrative overhead, defeating one of APPN's selling points, and is not very flexible in terms of alternate routes. As to your second approach, again refer to the Overview chapter which shows the types of network configurations you can create using combinations of APPN, VTAM V4R1 interchange node, subarea, and SNI. It's true that you can have just about any arbitrary combination of networks and that SNI can provide interconnection between different NETID subnetworks, as it does today, in effect extending the scope of APPN internetworking without border node. However, SNI is still subarea SNA, and still requires significant administrative effort to establish adjacent SSCP definitions, ER and VR definitions, mode and COS mappings, etc. SNI has the advantage of policy-based routing (using "user exits") which is good from an administrative standpoint for access control, accounting, security, etc. SNI has the drawback (from an APPN standpoint) of "assumed NETID" routing wherein the SSCP routing function will try different SNI-interconnected networks, substituting different NETIDs until it finds one where the LUNAME portion of the fully-qualified NETID.LUNAME matches. Thus it creates a flat namespace across several domains. So while the SNI approach to interconnecting APPN and subarea networks works, I'd view it as a migration step on the way to full APPN. APPN has full support for NETID.LUNAME, and Extended Border Node will replaceme SNI in terms of the opportunity to implement routing policies. Security(Public/Private): Public Architect: Marcia Peters Comments: ----- APPNQA FORUM appended at 17:42:07 on 93/07/22 GMT (by HEFEL at RALVM6) -- Subject: Peripheral Border Node Ref: Append at 15:19:09 on 93/07/21 GMT (by HEFEL at RALVM6) Date: 07/19/93 Owner: Anonymous Compuserve? Question: Today we are using on the mainframe VTAM 3.4.1 and OS/400 2.1 on the AS/400 side. We can attach a AS/400 (with some limits) with a different NETID to the SNA-network using NNNA. When we install now VTAM 4.1, then our SNA-Network will get a Composite Network Node (including old PU4 and PU5). VTAM 4.1 does not include a border-node-function. Question: --------- Do we still need to connect AS/400 as LEN - Node with NNNA (Non-Native-network-attachement)? Does the AS/400 provide the border-node function, that is missing in VTAM 4.1 and we can then connect the AS/400 to the new Network-Node with VTAM 4.1 and NCP 6.2) with a different NETID ?? If the pevious case will work, what are the limits (e.g. how many diffrentchained networks can be used) ? Thank you very much for your help. Answer: AS/400 peripheral border node function (only for use between 2 subnets, not multi subnets) was released in V2R1.0. To connect to the VTAM V4R1 however you must make sure that you have the latest level of PTFs for the AS/400 since there was a VTAM V4R1 accommodations PTF. If the AS/400 and VTAM have different NETIDs, the AS/400 border node can connect to the VTAM (acting as a network node). The VTAM sees the AS/400 as an end node and forwards searches to it. The AS/400 will then forward these searches into its local subnet. Searches originating in the AS/400 subnet for resources with the same VTAM NETID will be forwarded on to the VTAM. Security(Public/Private): Public Architect: Doyle Horne ----- APPNQA FORUM appended at 19:47:46 on 93/07/29 GMT (by HEFEL at RALVM6) -- Subject: Dependent LUs in APPN Ref: Append at 18:59:06 on 93/07/29 GMT (by HEFEL at RALVM6) Date: July 23, 1993 Owner: Rainer Foeppl Compuserve? Y Question: Let's take the following configuration: AS/400(Net1)---APPN---S/390(Net2) One question that occurs immediatley is What happens to dependent LU's which want to access an application on the host? If a AS400 is a LEN-Node there is no problem, but if they are a Network-Node ? Thanks for your help and have a nice weekend Rainer Answer: Here is how the AS400 works today. The dependent LUs come across the link from an AS/400(NN/EN) to a LEN S/390 where the AS/400 looks like a PU2.0. We also run 2.1 across that same link for APPC connections so that the one link supports 2.0 and 2.1. Once the link switches to NN-NN, we should continue to work as long as VTAM continues to send down the ACTPUs/ACTLUs that they do today for attached PU2.0s. Our dependent attachment only works if the AS/400 is boundary attached to the S/390 or SNA/PassThrough is used to get a dependent through a string of AS/400s into a subarea. Either way, the dependents still come into the S/390. Of course non-boundary attached AS/400 dependents that do not have an AS/400 only path into the subarea can not support dependent LUs. Security(Public/Private): Public Architect: Doyle Horne Comments: